Method and System for Displaying Anomalies in Time Series Data

ABSTRACT

A graphical user interface is used for presenting time series data and anomalies associated with a data source on a computer display. The graphical user interface has first and second windows. The first window includes a graph of time series data values for an attribute of the data source and a histogram of anomalies of the data source, each corresponding to a value of a respective attribute that is substantially different from an expected value of the attribute. The second window includes a list of automatic alerts characterizing a set of anomalies of the data source at a particular time. In response to a user adjustment of a sensitivity threshold, a new histogram of anomalies is rendered to replace the existing histogram of anomalies in the first window and a new list of automatic alerts is rendered to replace the existing list of automatic alerts in the second window.

PRIORITY

This application claims priority under 35 U.S.C. 119(e) to U.S.Provisional Patent Application 61/253,472 filed Oct. 20, 2009, which ishereby incorporated by reference in its entirety.

TECHNICAL FIELD

The disclosed embodiments relate generally to web analytics data mining,and in particular, to a system and method for detecting and displayingevents of potential interest in time series data.

BACKGROUND

Web analytics is the measurement, collection, analysis and reporting ofthe traffic data of a web site for purposes such as understanding andoptimizing web site usage. The traffic data is typically organized inthe form of one or more multidimensional datasets whose metadata mayinclude multiple dimensions and metric attributes (also known as“measures”). Conventional approaches typically generate multiple(sometimes hundreds of) reports by focusing on the factual aspects ofthe web traffic, e.g., by visualizing different subsets of amultidimensional dataset defined by various configurations of dimensionsand metric attributes. From examining the visualized traffic data, a webanalyst may be able to discover useful information for improving thequality and volume of the traffic to the web site. But this exercise ofsearching for useful information within the multidimensional dataset isnon-trivial especially if the volume of the traffic data is significantor the metadata includes a large number of dimensions and metricattributes that may correspond to hundreds or even thousands ofconfigurations. Because different configurations correspond to differentfactual aspects of the dataset, it is difficult to rank theconfigurations by their respective importance to the web analyst basedon a well-accepted standard.

SUMMARY

In accordance with some embodiments described below, acomputer-implemented method for detecting anomalies in time series dataat a server system is disclosed. The server system is connected to oneor more client devices through a network. The server system stores timeseries data for a data source. The time series data comprises aplurality of time-value pairs, each pair including a value of one ormore attributes associated with the data source and a time associatedwith the value. For a particular attribute, the server system generatesa plurality of forecasting models for characterizing the time-valuepairs in a respective subset of the time series data, each forecastingmodel including an estimated attribute value and an associatederror-variance. For a respective time-value pair associated with theparticular attribute, the server system determines whether the value ofthe time-value pair is within the error-variance of the correspondingestimated attribute value and tags the time-value pair as an anomaly ifthe value of the time-value pair is outside the error variance for atleast a first subset of the forecasting models. In response to a requestfrom a client application for analytics information for the data source,the server system reports to the client application at least a subset ofthe time-value pairs tagged as anomalies for one or more of theattributes.

In accordance with some embodiments described below, a server system foridentifying anomalies in time series data is disclosed. The serversystem is connected to one or more client devices through a network. Theserver system includes one or more processors for executing programs andmemory to store data and to store one or more programs to be executed bythe one or more processors. The one or more programs includinginstructions for: storing time series data for a data source, whereinthe time series data comprises a plurality of time-value pairs, eachpair including a value of one or more attributes associated with thedata source and a time associated with the value; for a particularattribute, generating a plurality of forecasting models forcharacterizing the time-value pairs in a respective subset of the timeseries data, each model including an estimated attribute value and anassociated error-variance; for a respective time-value pair associatedwith the particular attribute: determining whether the value of thetime-value pair is within the error-variance of the correspondingestimated attribute value; and tagging the time-value pair as an anomalyif the value of the time-value pair is outside the error variance for atleast a first subset of the forecasting models; and in response to arequest from a client application for analytics information for the datasource, reporting to the client application at least a subset of thetime-value pairs tagged as anomalies for one or more of the attributes.

In accordance with some embodiments described below, a computerreadable-storage medium stores one or more programs for execution by oneor more processors of a server system. The server system is connected toone or more client devices through a network. The one or more programsinclude instructions for: storing time series data for a data source,wherein the time series data comprises a plurality of time-value pairs,each pair including a value of one or more attributes associated withthe data source and a time associated with the value; for a particularattribute, generating a plurality of forecasting models forcharacterizing the time-value pairs in a respective subset of the timeseries data, each model including an estimated attribute value and anassociated error-variance; for a respective time-value pair associatedwith the particular attribute: determining whether the value of thetime-value pair is within the error-variance of the correspondingestimated attribute value; and tagging the time-value pair as an anomalyif the value of the time-value pair is outside the error variance for atleast a first subset of the forecasting models; and in response to arequest from a client application for analytics information for the datasource, reporting to the client application at least a subset of thetime-value pairs tagged as anomalies for one or more of the attributes.

In accordance with some embodiments described below, a graphical userinterface is disclosed for presenting time series data and anomalies fora data source on a display of a client computer having a user inputdevice. The graphical user interface includes a first window and asecond window below the first window on the display. The first window onthe display includes: a graph of time series data values for a firstattribute for the data source, the graph having a time axiscorresponding to a time range and a dependent data value axis, and ahistogram of anomalies for the data source, each of the anomaliescorresponding to a value of an attribute that is substantially differentfrom an expected value of the attribute, the histogram having the sametime axis scale as the graph and a dependent total anomalies axis. Theheight of a respective bar along the total anomalies axis represents atotal number of anomalies for the data source at a corresponding time onthe time axis. The second window on the display includes a list ofautomatic alerts characterizing a set of anomalies for the data sourceat a particular time on the time axis. The particular time is designatedby a user via interaction with the graph through the user input deviceand each item of the list of automatic alerts corresponds to an anomalyassociated with a respective attribute for the data source.

BRIEF DESCRIPTION OF DRAWINGS

The aforementioned embodiment of the invention as well as additionalembodiments will be more clearly understood as a result of the followingdetailed description of the various aspects of the invention when takenin conjunction with the drawings. Like reference numerals refer tocorresponding parts throughout the several views of the drawings.

FIG. 1A is an overview block diagram of an analytics system forcollecting web traffic data and performing web analytics on the data inaccordance with some embodiments.

FIG. 1B is an overview block diagram of the analytics system forpreparing and providing user-requested web analytics results to theusers at different clients accordance with some embodiments.

FIG. 2 is a block diagram of a data structure used in the hits database155 to store sessionized web traffic data at different web sites inaccordance with some embodiments

FIG. 3 is a block diagram of a data structure used in the aggregatesdatabase 165 to store aggregated web traffic data at different web sitesin accordance with some embodiments.

FIG. 4 is a block diagram of a data structure used in the time seriesdatabase 175 to store time series data extracted from the aggregated webtraffic data in accordance with some embodiments.

FIG. 5 is a block diagram of a data structure used in the eventsdatabase 185 to store events of potential interest detected in the timeseries data in accordance with some embodiments.

FIG. 6A is a flow chart of a process for updating the time series datausing the aggregated data updates in accordance with some embodiments.

FIG. 6B is a block diagram of an exemplary process for updating a timeseries on a weekly basis in accordance with some embodiments.

FIGS. 7A and 7B are flow charts of a model-based process for detectingevents of potential interest in a time series in accordance with someembodiments.

FIG. 7C is a flow chart of a rule-based process for detecting events ofpotential interest in a time series in accordance with some embodiments.

FIGS. 8A and 8B are flow charts illustrating how the analytics systemprepares and serves a report of events of interest in response to a userrequest in accordance with some embodiments.

FIG. 9 is a block diagram of a client device for requesting andrendering web analytics reports in accordance with some embodiments.

FIG. 10 is a block diagram of an analytics system for processing webtraffic data, identifying events of potential interest therein, andserving web analytics reports in response to user requests in accordancewith some embodiments.

FIGS. 11A to 11C are screenshots of graphical user interfaces thatdisplay daily, weekly, and monthly events of potential interest,respectively, in accordance with some embodiments.

FIGS. 12A to 12E are screenshots of graphical user interfaces thatdisplays information relating to events of potential interest inaccordance with some embodiments.

FIGS. 13A to 13C are screenshots of graphical user interfaces thatdisplay different numbers of events of potential interest based on arespective user-specified sensitivity threshold in accordance with someembodiments.

FIGS. 14A and 14B are screenshots of graphical user interfaces thatdisplay events of potential interest based on a respectiveuser-specified organization manner in accordance with some embodiments.

FIGS. 15A and 15B depict a flow chart of a method for identifyinganomalies in time series data in accordance with some embodiments.

FIGS. 16A and 16B depict another flow chart of a method for identifyinganomalies in time series data implemented by different components of aserver system with a processor and memory in accordance with someembodiments.

FIGS. 17A to 17C depict another flow chart of a method for detectinganomalies in web analytics data implemented at a server system inaccordance with some embodiments.

DESCRIPTION OF EMBODIMENTS

Reference will now be made in detail to embodiments, examples of whichare illustrated in the accompanying drawings. While the invention willbe described in conjunction with the embodiments, it will be understoodthat the invention is not limited to these particular embodiments. Forexample, although the embodiments below use web analytics forillustrative purposes. It will be apparent to those skilled in the artthat the inventions disclosed in this application can be used to analyzealmost any type of time series data regardless of whether the timeseries data is web-related or not. On the contrary, the inventionincludes alternatives, modifications and equivalents that are within thespirit and scope of the appended claims. Numerous specific details areset forth in order to provide a thorough understanding of the subjectmatter presented herein. But it will be apparent to one of ordinaryskill in the art that the subject matter may be practiced without thesespecific details. In other instances, well-known methods, procedures,components, and circuits have not been described in detail so as not tounnecessarily obscure aspects of the embodiments.

FIG. 1A illustrates a distributed computer system 100 in accordance withsome embodiments. The distributed system 100 includes one or more webservers 120 that host web sites and serve web pages upon receivingrequests from clients 110. In some embodiments, the web servers 120collect web traffic data in logfiles 130. In some other embodiments, theweb pages hosted by the web servers 120 include one or more embeddedcomputer programs such as Javascript codes for capturing the web trafficdata. When a user requests and downloads the web pages to a client 110,the embedded computer programs also reside in the client 110 and monitorthe user's activities on the web pages. This approach can avoid some webcaching-related issues and is sometimes referred to as “page tagging.”In some embodiments, a web server 120 may employ both mechanisms forgathering web traffic data.

The distributed system 100 includes an analytics system 140 thatincludes a log processor 150 for extracting web page hit data from thelogfiles 130 or receiving web page hit data captured by the embeddedcomputer programs from the clients 110 and storing the hit data in ahits database 155. One or more aggregation servers 160 process the hitdata and generate aggregated web analytics data that is stored inaggregates database 165. The time series gathering servers 170 extractor receive newly aggregated data from the aggregates database 165 andcreate or update a plurality of time series for each web site, which arestored in the time series database 175. In some embodiments, the timeseries gathering servers 170 also extract web analytics data from thehits database 155. One or more event detection servers 180 process thetime series in the database 175 at regular time interval (e.g., nightly,weekly or monthly) to detect events of potential interest therein andstore the events in the events database 185. In some embodiments, theevent detection process is a rule-based one in which the event detectionservers 180 extract user-specified alert rules from the alert rulesdatabase 195. The analytics system 140 includes a query processor 190for accessing the aggregates database 165, the time series database 175,and the events database 185, and returning the query results as webanalytics reports to users of the analytics system 140 (who use theanalytics system to track the visitors' activities at one or more oftheir web sites). If the user-requested data has not been aggregated,the query processor 180 reads the raw hits data in real time andcomputes the desired aggregates from it.

In some embodiments, the analytics system 140 processes and returns aset of the web analytics reports that correspond to a desired data viewspecified by a user. In some embodiments, the analytics system 140identifies those hits in the hits database 155 that arecontext-insensitive and processes these hits to incrementally update afirst plurality of aggregate tables in the aggregates database 165. Theanalytics system 140 identifies those hits in the hits database 155 thatare context-sensitive and processes these hits to incrementally update asecond plurality of aggregate tables using the second context-sensitiveentries, but only, at the end of the specified period of time, such asat the end of the day. Doing so speeds up the incremental updates tomore than 90% of the data, as discussed below.

The distributed system 100 also includes a plurality of data servers 106that store one or more data structures, such as tables, that may be usedby the analytics system 140 for storage. In some embodiments, the dataservers 106 store the logfiles 130, the hit data 155, the aggregate data165, the time series data 175, and/or the events data 185. In someembodiments, data servers 106 are clustered in a data center or in twoor more interconnected data centers. In some embodiments, thedistributed system 100 includes as many as 1000 data servers or more.The various components of the distributed system 100 are interconnectedby a network 102. The network 102 may be any suitable network, includingbut not limited to a local area network (LAN), a wide-area network(WAN), the Internet, an Ethernet network, a virtual private network(VPN), or any combination of such networks. The network 102 can be wiredor wireless. In some embodiments, the network 102 uses the HyperTextTransport Protocol (HTTP) and the Transmission Control Protocol/InternetProtocol (TCP/IP) to transport information between different networks.The HTTP permits client devices to access various information itemsavailable on the Internet via the network 102. The various embodimentsof the invention, however, are not limited to the use of any particularprotocol.

Typically, where an individual visitor directly accesses a web pageserved by a web server 120, the log data entry (stored in one or moredatabases represented by logfiles 130 or captured by the computerprogram embedded in the web page) records multiple variables about thevisits, typically including the IP address, the user agent, the web pageviewed, the time and date that the web page was accessed and a statusfield. Each data entry in a log file represents a single “hit” on a filehosted by a web server 120, and consists of a number of fields(explained below in connection with FIG. 2). Any server request isconsidered a hit. For example, when a visitor calls up a web page withsix images, that is seven hits—one for the page, and six for the images.

In other circumstances, the visitor may have employed a query in asearch engine and the web-site under scrutiny was turned up in thesearch results. In such case, the corresponding entry in the log datamay reveal a “reference” and the “search term” entered by the visitor.In some circumstances, the visitor is not an individual, but rather asoftware process such as an Internet robot, web crawler or spider, linkchecker, mirror agent, hacker, or other such entity used tosystematically peruse vast amounts of data available via the network102. The log data entry corresponding to such accesses may display an IPaddress, host name and/or user agent that may be associated with suchentities.

Another type of data that may be recorded in a log file 130 is a sessionidentifier or session ID, which is a unique identifier (such as, afixed-length alphanumeric string) that a web server assigns to aspecific user for the duration of that user's visit and that identifiesthe user's session (maybe a series of related message exchanges).Session identifiers become necessary in cases where the communicationsinfrastructure uses a stateless protocol such as HTTP. For example, abuyer who visits a seller's web site wants to collect a number ofarticles in a virtual shopping cart and then finalize the shoppingtransaction by going to the site's checkout page. This typicallyinvolves an ongoing communication including several web pages requestedby the client 110 and sent back by the server 120. In such a situation,it is vital to keep track of the current state of the shopper's cart,and a session ID is one way to achieve that goal.

A session ID is typically granted to a visitor on his first visit to aweb site. It is different from a user ID because sessions are typicallyshort-lived (they expire after a preset time of inactivity which may beminutes or hours) and may become invalid after a certain goal has beenmet (for example, once the buyer has finalized his order, he can not usethe same session ID to add more items).

FIG. 1B illustrates the distributed system 100 with an emphasis on theclient-server interactions in accordance with some embodiments. A client110 (also known as a “client device”) may be any computer or similardevice through which a user of the client 110 can submit data accessrequests to and receive results or other services from the analyticssystem 140. Examples include, without limitation, desktop computers,laptop computers, tablet computers, mobile devices such as mobilephones, personal digital assistants, set-top boxes, or any combinationof the above. A respective client 110 may contain at least one clientapplication 112 for submitting requests to the analytics system 140. Forexample, the client application 112 can be a web browser or other typeof application that permits a user to access the services provided bythe analytics system 140.

In some embodiments, the client application 112 includes one or moreclient assistants 114. A client assistant 114 can be a softwareapplication that performs tasks related to assisting a user's activitieswith respect to the client application 112 and/or other applications. Insome embodiments, a client assistant 114 includes a local copy of theexecutable version of the embedded computer programs for collecting webanalytics data relating to web pages from a particular web site. Forexample, the client assistant 114 may assist a user at the client 110with browsing information (e.g., web pages), processing information(e.g., query results) received from the analytics system 140, andmonitoring the user's activities on the query results. In someembodiments, the client assistant 114 is embedded in a web page (e.g., aquery results web page) or other documents downloaded from the analyticssystem 140. In some embodiments, the client assistant 114 is a part ofthe client application 112 (e.g., a plug-in application of a webbrowser). The client 110 further includes a communication interface 118to support the communication between the client 110 and other devices(e.g., the analytics system 140 or another client 110).

In some embodiments, the query processor 190 includes a web interface192 (sometimes referred to as a “front-end server”) and a serverapplication 194 (sometimes referred to as a “mid-tier server” or“mid-tier API”). The web interface 192 receives data access requestsfrom client devices 110 and forwards the requests to the serverapplication 194. In response to receiving the requests, the serverapplication 194 processes the requests including generating databasequeries associated with a request, applying the queries to differentdatabases for data requested by the client, and returning the queryresults to the requesting clients 110. After receiving a result, theclient application 112 at a particular client 110 displays the result tothe user who submits the original request.

In some embodiments, each of the databases shown in FIGS. 1A and 1B iseffectively a database management system including a database serverthat is configured to manage a large number of data records stored inthe corresponding database. In response to a query submitted by theserver application 194, the database server identifies zero or more datarecords that satisfy the query and returns the data records to theserver application 194 for further processing. In some embodiments, theanalytics system 140 is an application service provider (ASP) thatprovides web analytics services to its customers (e.g., a web siteowner) by visualizing the web traffic data generated at a web site inaccordance with various user requests.

FIG. 2 is a block diagram of a data structure used in the hits database155 to store sessionized web traffic data at different web sites inaccordance with some embodiments. The web traffic data stored in thedata structure 200 have a hierarchical structure. The top level of thehierarchy corresponds to different web sites 200A, 200B (i.e., differentweb servers). For a respective web site, the traffic data is groupedinto multiple sessions 210A, 210B, and each session having a uniquesession ID 220. A session ID uniquely identifies a user's session withthe web site 200A for the duration of that user's visit. Within asession 210A, other session-level attributes include the operatingsystem 220B (i.e., the operating system the computer runs on from whichthe user accesses the web site), the browser name 220C (i.e., the webbrowser application used by the user for accessing the web site) and thebrowser version 220D, geographical information of the computer such asthe country 220E and the city 220F, etc.

For convenience and custom, the web traffic data within a user session(or a visit) is further divided into one or more hits 230A to 230N. Notethat the terms “session” and “visit” are used interchangeably throughoutthis application. In the context of web traffic, a hit typicallycorresponds to a request to a web server for a document such as a webpage, an image, a JavaScript file, a Cascading Style Sheet (CSS) file,etc. Each hit 230A may be characterized by attributes such as the typeof hit 240A (e.g., transaction hit, etc.), the referral URL 240B (i.e.,the web page the visitor was on when the hit was generated), thetimestamp 240C that indicates when the hit occurs and so on. Note thatthe session-level and hit-level attributes as shown in FIG. 2 are listedfor illustrative purposes only. As will be shown in the examples below,a session or a hit of web traffic data may include many other attributesthat either exist in the raw traffic data (e.g., the timestamp) or canbe derived from the raw traffic data by the analytics system 150 (e.g.,the average pageviews per session).

As noted above in connection with FIG. 1A, the aggregation servers 160is responsible for aggregating the data records in the hits database 155at a regular time interval (e.g., per day or per hour) based on theirrespective session IDs and other dimension or metric attributes. Forexample, the aggregation servers 160 may determine the total number ofvisits to a web site during one day by counting the number of sessionsassociated with the web site for the same day. The aggregation servers160 may also determine the total number of visits to a web site using aparticular type or even version of web browser during one day bycounting the number of sessions associated with the web site for thesame day that have the specified type or even version of web browser. Insome embodiments, the aggregation servers 160 determine values forhundreds or even thousands of predefined attributes based on the hitsdata records and store the determined values and their associatedattributes in a data structure like the one shown in FIG. 3 inaccordance with some embodiments.

In some embodiments, the aggregated data stored in the data structure300 also has a hierarchical structure. The top level of the hierarchycorresponds to different sources 300A, 300B (e.g., different web sites),each source having a unique source ID 310A. For each source, there areat least two types of aggregated data. The aggregated metrics 310Binclude those attributes and associated values that are determined fromthe hits data for a predefined period of time without applying anyrestrictions. For example, if the predefined period of time is one day,the visits attribute 320A may be associated with one or more pairs of(time, value) 330A in which the time represents a specific day such asOct. 16, 2009 and the value represents the total number of visits (orsessions) during the same day regardless of, e.g., which country or cityeach visit is from. Similarly, the pageview attribute 320B is alsoassociated with one or more pairs of (time, value) 330B in which thetime represents a specific day and the value represents the total numberof pageviews during the same day regardless of, e.g., what web browseris used for each pageview.

In some embodiments, a breakdown of a lump sum metric value (e.g., thevisits 320A) into multiple values defined by different conditions isdesired because it can provide more information to a web analyst aboutthe web traffic. For example, the conditions 310C limit the aggregationof web traffic data for a particular web site to sessions whose countryis China. In this case, the aggregation servers 160 generate another setof aggregated metrics 320C by skipping any session whose country is notChina. Similarly, the conditions 310D focuses only on the sessions thatuse Firefox as the web browser. Accordingly, the aggregated metrics 320Dshould not take into account of any session that uses Internet Explorer.Note that some of the condition-free aggregated metrics 310B may bederived from the conditioned aggregated metrics 320C, 320D. In someembodiments, the aggregate servers 160 typically pre-compute values formany hundreds of aggregated metrics with or without conditions and storethose values in the aggregates database 165 for future use.

One use of the aggregates database 165 is to detect events of potentialinterest in the web analytics data and present them to a web analyst inan intuitive manner. An event of potential interest (also referred to asan alert or an anomaly in this application) is something that might bevaluable to the web analyst but is hidden in the vast amount of webtraffic data and difficult to identify. For example, after posting anadvertisement on a web site, a market analyst is very interested inlearning the advertisement's effectiveness in terms of whether there isany traffic increase at the web site during a predefined time period,from what source it sees the largest traffic increase or decrease, andhow much of the increased web traffic is related to the advertisement(e.g., as measured by the click-through rate). As another example, awebmaster concerned with the security of a web site is interested inlearning about abnormal web traffic patterns as early as possible toprevent serious attacks.

Without the support by the features as described in this application, itmay take many hours or even days of effort for a web analyst to “plow”through the massive amount of web analytics data and track down someuseful information. This approach not only wastes human resources butalso reduces the value of the information due to the time lapse. Oneaspect of the present application is to develop a system that canautomatically detect those events of potential interest from the webanalytics data with no or minimal user effort and present the detectionresult to the web analyst in an efficient and user-friendly manner tohelp the web analyst's decision making process.

According to some embodiments, the process of identifying any events ofpotential interest in the web analytics data begins with deriving anumber of time series or time sequences from the aggregated webanalytics data stored in the data structure shown in FIG. 3 and storethe time series in another data structure for further processing. Aswill be described below, at least two ways of detecting events ofpotential interest are disclosed in the present application: (i)model-based event detection; and (ii) rule-based event detection.

Generally, the model-based event detection method described hereinapplies one or more statistical models to a time series to forecast orpredict or estimate one or more values for a future time period and thencompares the predicted values with the actual value when available. Ifthe differences between the predicted values and the actual value meet apredefined condition, an event of potential interest or an anomaly isidentified for the corresponding time period. To some extent, therule-based approach combines the prediction models and the predefinedcondition of the model-based approach into a user-specified alert rule.For example, one alert rule may specify that an event of potentialinterest is detected if the revenue metric attribute of a website at aparticular date drops at least 15% than the revenue metric attribute ofthe same website at the same date of the previous year.

In some embodiments, the model-based or rule-based event detectionmethod can also be performed on a collection of time series data, e.g.,in a batch mode, to not only predict anomalies in the future (which istypically the current day, week, or month) but also identify anomaliesin the past. In some embodiments, the anomaly prediction for the currenttime period (e.g., today, this week or month) may only involve the datasamples collected in the past and not include any data samples collectedduring the current time period. In this case, the prediction for thecurrent time period may start right after the time series update withthe data samples of the immediately previous time period. In some otherembodiments, the anomaly prediction for the current time period uses thedata samples from the current time period as well.

FIG. 4 is a block diagram of a data structure that stores time seriesdata extracted from the aggregated web traffic data in accordance withsome embodiments. In some embodiments, the time series data stored inthe data structure 400 has a hierarchical structure. The top level ofthe hierarchy corresponds to different sources 400A, 400B (e.g.,different web sites), each source having a unique source ID 410A. Notethat the source ID 410A may be the same as the source ID 310A for thesame source. Like the multiple aggregated metrics 310B, 320C, 320Dstored in the data structure 300, each source in the data structure 400may be associated with a plurality of time series, each time serieshaving a unique combination of metric and condition.

For example, the metric 410B is the number of new visits to a websiteduring a day and the condition 410C is that only new visits that comefrom Paris should be considered. In this case, the time series 410Dincludes a time series ID 420A and one or more time series updates 420B,420C and each time series update includes one or more pairs of (time,value) 430A wherein the “time” parameter corresponds to a particular dayand the “value” parameter corresponds to a particular number of newvisits from Paris during that day. A more detailed example of a timeseries including multiple updates is provided below in connection withFIG. 6B.

Generally, each source may be characterized by hundreds of metric anddimension attributes in the hits database 155. Different combinationschemes of the metric and dimension attributes may produce thousands ofpossible time series. From a web analyst's perspective, not everypossible time series is important enough to justify a spot in the timeseries database 175. Although a bit arbitrary, each (condition-free orconditioned) time series stored in the time series database 175 isgenerated because it may carry information of interest to many webanalysts. In some embodiments, a web master of a website is allowed todefine his or her own new metric or dimension attributes or customizethe existing metric or dimension attributes to have a bettercharacterization of the traffic to the website. In this case, the new orcustomized attributes are additional sources for generating time seriesdata for event detection using the invention disclosed in thisapplication. A more detailed description of how to define new orcustomize existing attributes can be found in a pending applicationentitled “Extensible custom variables for tracking user traffic”(attorney docket number 060963-5420-US) filed Oct. 20, 2009, which ishereby incorporated by reference in its entirety.

In some embodiments, the time series in the data structure 400 arederived from the aggregated data in the data structure 300 of FIG. 3. Ifa time series corresponds to the aggregated metrics of an entire sourcefree of any precondition, the condition for this time series in the datastructure 400 does not exist or is none. In this case, the time seriesis also referred to as a “condition-free” time series. If a time seriescorresponds to the aggregated metrics of the source with one or moreconditions, the same conditions used for aggregating the web trafficdata are also the conditions in the data structure 400 for thecorresponding time series. In this case, the time series is alsoreferred to as a “conditioned” time series. In some embodiments, asource has a number (e.g., 10) of condition-free time series includingthe metrics like visits, pageviews, bounce rate, pages/visit, newvisits, and average time on site, etc. In addition, the source may havemore (e.g., 100) conditioned time series, each having a unique set ofconditions for filtering out data that does not meet any of thepredefined conditions.

In some embodiments, if the definition of a time series does not haveany corresponding entry in the aggregates database 165, the time seriesgathering servers 170 may need to access the hits database 155 to buildthe time series directly on top of the hits data or even the raw webtraffic data from the logfiles 130 or the Javascript code of a clientassistance 114 that monitors the user activities at a web page. In someother embodiments, the time series gathering servers 170 can send arequest to the aggregation servers 160 for aggregating the hits dataaccording to the time series definition and return the aggregated datato the time series gathering servers 170.

Although the time series database 175 does not include every possibletime series that can be derived from a website's hits data, it is achallenge for the time series database 175 to host so many time seriesrelated to different sources. In some embodiments, some dataquantization and compression techniques may be employed to keep the timeseries storage relatively small. For example, a value in the time seriesdatabase 175 is rounded and stored in the form of an expression likea*2^(b), where the parameter “a” is encoded with a small number (e.g.,5) of bits and the parameter “b” can have more bits such that thedifference between the value and the expression is as small as possible.This data quantization scheme is acceptable as long as the loss ofprecision does not defeat the purpose of detecting those events ofpotential interest.

For a given time series (e.g., the number of daily visits during amonth), each value at a particular date may be a very large number(e.g., three or four digits) but the difference between two consecutivedates may be much smaller (e.g., only two digits). Instead of storingthe actual values like v₁, v₂, v₃, etc., one way of saving the storagespace in this situation is to calculate the difference between twoconsecutive values and store the differences like v₂-v₁, v₃-v₂, etc. inthe time series database 175 as long as the base value v₁ is availablefor reconstructing the actual values when needed.

FIG. 5 is a block diagram of a data structure that stores events ofpotential interest detected in the time series data in accordance withsome embodiments. The events data stored in the data structure 500 alsohas a hierarchical structure. The top level of the hierarchy correspondsto different sources 500A, 500B (e.g., different web sites), each sourcehaving a unique source ID 510A. Note that the source ID 510A may be thesame as the source ID 310A in the aggregates database 165 and the sourceID 410A in the time series database 175 for the same source. Each event510B is associated with an event ID 510C, a metric 520A, one or moreconditions 520B, a pair of (time, value) 520C wherein the value is theactual value for that time period, a pair of (minimum, maximum) 520Dwherein the minimum and maximum values are usually determined throughone or more statistical models, a significance factor 520E thatindicates the interest level of this event to a web analyst, etc. A moredetailed description of the (minimum, maximum) pair and the significancefactor is provided below in connection with FIGS. 7A and 7B.

Having described the data structures of the time series database 175 andthe events database 185, we now discuss the process performed by thetime series gathering servers 170 for updating the time series database175 and the process performed by the event detection servers 180 forupdating the events database 185. For convenience, it is assumed thatthat the initial setup of the analytics system 140 is completed anddifferent components within the system 140 are in a normal operationmode.

FIG. 6A is a flow chart of a process for updating the time series datausing the aggregated data updates in accordance with some embodiments.

At a regular time interval (e.g., every few hours or every night), thetime series gathering servers 170 receive one or more aggregated dataupdates (610). In some embodiments, an aggregated data update providesinformation about the user activities at one or more websites during therecent predefined time interval. For example, the update may include anumber of visits to a particular website or any other aggregated metricsthat have been collected in the time series database 175. It should benoted that, as explained earlier, the invention of this application isnot limited to web traffic data. In fact, it can be used to identify orpredict anomalies in almost any type of time series data. In someembodiments, the updates are pulled out of the aggregates database 165by the time series gathering server 170. In some other embodiments, theaggregation servers 160 push the updates to the time series gatheringservers 170 for further processing.

For each update, the time series gathering servers 170 identify the timeseries in the database 175 for updating (620). As noted above, the timeseries data in the time series database 175 are organized underdifferent sources as different sets of metrics and conditions. At apredefined time (e.g., every night), the time series gathering servers170 collect the aggregated data updates corresponding to different timeseries and then apply each of them to a corresponding time series in thedatabase 175. In some embodiments, the metric and dimension attributesassociated with different updates are part of the key for identifyingthe corresponding time series in the database 175. In some embodiments,the data structure of the aggregated data updates is similar to the datastructure 300 in FIG. 3. For each source ID in the update, the timeseries gathering servers 170 find the corresponding entry in the datastructure 400 in FIG. 4 that has the same source ID. Next, the timeseries gathering servers 170 update the identified time series using thedata entries in the update (630) and consolidates the time seriesupdates if predefined conditions are met (640).

FIG. 6B is a block diagram of an exemplary process for updating a timeseries on a weekly basis in accordance with some embodiments. In thisexample, it is assumed that the updates to the time series database 175happen on a daily basis and a time series consolidation process occursevery week.

On Sunday, the time series 650 includes only one time series update650-0. The time series update 650-0 includes a plurality of (time,value) pairs, one pair per day and each value corresponding to an actualvalue for that day. In some embodiments, the oldest entry of these(time, value) pairs may be dated a long time (e.g., two years) back andthe newest entry (T_(N), V_(N)) is generated this Sunday. As will beexplained below in detail, each time series is used for predicting oneor more values at a future time under different prediction models. Insome embodiments, the daily time series are summed on a weekly basis toform a weekly time series, which may be further summed on a monthlybasis to a monthly time series. Note that this summation operation issimilar to a low-pass filter of the data samples. As a result, both theweekly time series and the monthly time series are typically smootherthan the corresponding daily time series during the same time period. Asshown in FIGS. 11A to 11C, this could result that an anomaly identifiedin the daily time series does not have an anomaly in the correspondingweek of the weekly time series or the corresponding month of the monthlytime series.

On Monday, the time series gathering servers 170 receive a time seriesupdate 650-1. In some embodiments, this update is stored as a separatetime series update entry 420C in the data structure 400 without beingcombined with the time series update 650-0. By doing so, it isconvenient for the servers 170 to add and access new entries into thedata structure 400. This process repeats every day and a new time seriesupdate 650-2 to 650-6 are added to the time series 650 until the nextSunday.

Upon receiving a new update entry (T_(N+7), V_(N+7)) on the next Sunday,the time series gathering servers 170 determine that it is time toconsolidate the time series updates accumulated during the past week. Insome embodiments, the time series gathering servers 170 follows thefirst-in-first-out (FIFO) rule by eliminating the oldest seven (time,value) pairs ranging from (T₀, V₀) to (T₆, V₆) from the time series 650and combining the newest seven (time, value) pairs ranging from(T_(N+1), V_(N−1)) to (T_(N+7), V_(N+7)) with the time series 650 toform a new time series 655 that includes only one time series update655-0. By repeating this process on a regular basis, the time seriesgathering servers 170 maintain a sliding time window on a fixed lengthof time series data when determining the existence of any events ofpotential interest. It should be noted that the method of updating timeseries as described above in connection with FIG. 6B is for illustrativepurposes. There are many other ways of managing the time series that areknown in the art.

In some embodiments, an event of potential interest has a practical,meaningful value only if the corresponding web site has received asufficient number of visits from a broad scope of visitors for a certaintime period. For example, if a website only receives a handful (e.g.,less than 10) of visits per day, a small, insignificant variation ofuser activities (e.g., an increase of daily visits from 10 to 30) couldresult in a false-alarm-like event of potential interest being detectedby the event detection servers 180. Too many false-alarm-like events ofpotential interest would likely make the actual events of interest lessvisible to the web analyst. To solve this problem, the time seriesgathering servers 170 may set a threshold such that no time series isgenerated for a website until the website's associated web analyticsdata reaches the threshold. For example, the threshold can be that awebsite receives at least 100 visits per day or 50 visits from distinctIP addresses. This lower-bound on the generation of time series reducesnot only the statistical noise level of the detected events of potentialinterest but also the storage needed for storing the time series.

For a given set of times series associated with a particular source, theevent detection servers 180 are responsible for identifying events ofpotential interest therein and populating the identified events in theevents database 185. As noted above, there are at least (i) model-basedand (ii) rule-based two different ways of detecting events, which willbe described in more detail below.

FIGS. 7A and 7B are flow charts of a model-based process for detectingevents of potential interest in a time series in accordance with someembodiments. In some embodiments, this process occurs periodically(e.g., every night). In some other embodiments, this process isperformed in response to a user request from a client 110. Forsimplicity, it is assumed in the example below that the event detectionservers 180 work on the time series at a predefined time. Afteridentifying and extracting a time series and its recent update from thetime series database 175 (710), the event detection servers 180 makepredictions for the time series using a plurality of prediction models.

For example, assume that the event detection servers 180 have a timeseries of the last N days of numbers of visits to a website and thenumber of visits for the current day. Whether the number of visits forthe current day is high or low enough to be qualified as an event ofpotential interest, the event detection servers 180 need to determinethe trend of the number of visits at the website and use the trend toestimate a predicted number of visits for the current day using the timeseries of the last N days of numbers of visits (note that the value of Nmay vary for different forecasting models). Although many statisticalmodels can be used to making the prediction. Two types of modelingtechniques are described herein for illustration: (i) linear regression;and (ii) Holt-Winters exponential smoothing.

Generally, linear regression is an approach of modeling a linearrelationship between a dependent variable y and one or more independentvariables x₁, x₂, . . . , x_(n), such that the linear model's unknownparameters can be estimated from the observed data. Assuming that therelationship between the number of visits (v_(i)) and the correspondingdate (t_(i)) is linear, this relationship can be mathematicallyexpressed as follows:

v _(i) =αt _(i)+β,

where t_(i)=1, 2, . . . , N or (in the form of matrix)

$\begin{bmatrix}v_{1} \\v_{2} \\\cdots \\v_{N}\end{bmatrix} = {\begin{bmatrix}t_{1} & 1 \\t_{2} & 1 \\\cdots & 1 \\t_{N} & 1\end{bmatrix}\begin{bmatrix}\alpha \\\beta\end{bmatrix}}$

A numerical solution to the matrix of linear equations (e.g., using thewell-known least-squares algorithm) can determine the two parameters αand β. Using the estimated {circumflex over (α)} and {circumflex over(β)}, it is possible to predict the number of visits (v_(j)) at anygiven date in the future (t_(j)) as follows:

v _(j) ={circumflex over (α)}t _(j)+{circumflex over (β)}.

From the time series of the actual numbers of visits at different dates,it is also possible to determine a variance for the predicted number ofvisits at the given date using well-known statistics theory. As aresult, an estimated range of the number of visits at a given date usinglinear regression can be expressed as follows:

[v_(j)−s_(j), v_(j)+s_(j)]

where s_(j) represents the variance of the prediction using linearregression.

Unlike the linear regression that gives the past observations equalweight, exponential regression is an approach that assigns exponentiallydecreasing weights to the past observations as they get older. Assumingthat the sequence of observations begins at time t=0, one form ofexponential smoothing (i.e., single exponential smoothing) is given bythe following formulas:

w₀=v₀,

w _(i) =λv _(i)+(1−λ)w _(i−1)

The parameter λ helps to define the amount of weight given to a pastobservation. Generally, the weight given to the observation at thek_(th) day in the past from the current date is expressed as:

λ(1−λ)^(k−1)

In some embodiments, another form of exponential smoothing (i.e., doubleexponential smoothing) is used for making the forecasting to capture atrend in the time series, if there is any. Double exponential smoothingis given by the following formulas:

w₀=v₀,

b ₀ =v ₁ −v ₀,

w _(i)=αv_(i)+(1−α)(w _(i−1) +b _(i−1)),

b _(i) =γ(w _(i) −w _(i−1))+(1−γ) b_(i−1)

where 0≦γ≦α≦1.

In some embodiments, the parameter γ is set to be no greater than theparameter α. In some embodiments, other non-linear statistical modelingschemes such as the triple exponential smoothing may be used to takecare of the seasonality (also known as periodicity) in the time seriesdata, which feature is typically prominent when a long time series isused for forecasting and the time series itself demonstrates some cyclicpatterns. For example, some websites such as a weather forecastingwebsite usually receive more traffic every Friday of each week becausemany visitors are interested in learning the weather condition duringthe weekend. In this case, the number of visits to the website may showa fluctuating pattern on a weekly basis and the triply exponentialsmoothing may be more appropriate for capturing the trend accurately.

In either modeling technique, the number of past observations or actualdata samples used for predicting the future value affects the predictedvalue's sensitivity to the recent changes of the actual data samples. Insome embodiments, three time-window lengths, i.e., 4 days, 21 days, and56 days, are chosen as the numbers of past observations used for makingseparate predictions so as to capture both the recent changes of theactual samples and the long-term trends using different predictions ifthe predicted values are daily-based or weekly-based. If the predictedvalues are monthly-based, the three time-window lengths arerespectively, 0.5 month, 3 months, and 8 months according to someembodiments. Note that the length of a time window used for predicting avalue at a future time, to some extent, determines whether the predictedvalue is more or less likely to be affected by a recent fluctuation inthe time series. A prediction model that uses a longer time windowconsiders more data samples into the past for forecasting a value in thefuture. This effect is similar to a low-pass filter such that thepredicted outcome is less sensitive to the recent fluctuation in thetime series and it is more likely to capture the trend in the timeseries. By contrast, a prediction model based on a short time windowuses fewer data samples to make the prediction and the predicted resultis usually more sensitive to the recent fluctuation in the time series.A combination of the predicted values based on the different lengths oftime series may result in a more reliable prediction that takes intoaccount both the long-term and short-term features in the time series.

In some embodiments, the event detection servers 180 make ninepredictions using the two modeling techniques and the three differentlengths of time windows. For convenience, the nine predictions areexpressed as:

[M_(i), e_(i)]

where i=1, 2, 3, 4, 5, 6, 7, 8, 9;

-   M_(i) represents the i_(th) predicted metric value at the current    date; and-   e_(i) represents the variance of the i_(th) prediction at the    current date.

In particular, three out of the nine forecasted models are derived fromlinear regression and the other six models are from double exponentialsmoothing because three possible values {x₁, x₂, x₃}, which are rankedin a monotonically increasing order, are candidates for each of the twoparameters α and γ. As noted above, γ is set to be no greater than α.Therefore, the three possible values {x₁, x₂, x₃} produce six differentcombinations that correspond to the six models as follows:

[α=x₁, γ=x₁],

[α=x₂, γ=x₁],

[α=x₃, γ=x₁],

[α=x₂, γ=x₂],

[α=x₃, γ=x₂],

[α=x₃, γ=x₃].

With the multiple predictions in hand, the event detection servers 180compare the actual value of the current date with each of the sixpredictions (720). Based on the comparison result, the event detectionservers 180 determine whether an event of potential interest is detectedor not (740). For each determined event, the event detection servers 180also give it a significance factor that indicates how unlikely the eventis (750) and stores the event in the events database 185 (760). Ingeneral, the more unlikely the event is, the more interested the webanalyst may be. For example, if there is an event indicating asignificant jump in the number of visits at a particular day whencompared with the trend in the past, the web analyst would probably liketo investigate the cause behind this jump and find out, e.g., whether itrelates to a potential hacker's attack or a successful commercialpromotion that immediately preceded the event. Note that not every eventidentified by the analytics system 140 may deserve an increased level ofuser attention. But by displaying a number of events or anomalies foreach day or week or month, the analytics system 140 presents to a usersuch as a web analyst a highly-reliable “roadmap,” with which the webanalyst can quickly “plow” through a large amount of web traffic dataand derive information valuable for improving the quality of serviceoffered by the website.

Assume that:

-   -   the time series being analyzed is the total number of daily        visits to a website during a particular date;    -   the six predictions are [344, 15], [500, 154], [402, 23], [389,        73], [588, 112], and [693, 87]; and    -   the actual number of visits is 618.

As shown in FIG. 7B, the event detection servers 180 select the firstpredicted model (720-1) and determines that the estimate and varianceare [344, 15] (720-2). A comparison of the actual number 618 with thepredicted model indicates that the actual number is not within the scopedefined by the model (730-1, no). In this case, the event detectionservers 180 further determine a significance factor for the first model.In some embodiments, the significance factor is determined bycalculating the extent of stretching the variance of the model toinclude the actual number within the stretched scope of the first model.For example, the significance factor for the first model can be(618−344)/15=18.3.

Since there are still five models left for comparison (730-3, no), theevent detection servers 180 then return to select the second model,[500, 154]. This time, the comparison indicates that the actual number618 is within the scope of the second model (730-1, yes) and the eventdetection servers 180 then go ahead working the next model under thelast model is processed (730-3, yes). In this example, three out of thesix models, i.e., [500, 154], [588, 112], and [693, 87] are satisfied bythe actual number 618 and three other models, i.e., [344, 15], [402,23], and [389, 73] are not satisfied by the actual number 618. Assumingthat the threshold for detecting an event is that at least half of themodels are not satisfied (740-1), the event detection servers 180 thendetermine that the actual number of visits 618 is an event of potentialinterest (740-2) and chooses a significance factor for the event(740-3).

In some embodiments, the significance factor of an event is thesignificance factor of one of the unsatisfied prediction models suchthat (i) the actual number is more likely to satisfy this predictionmodel than any other unsatisfied prediction models and (ii) the actualnumber would satisfy more than half of all the prediction models bysatisfying this prediction model and therefore no longer qualify as anevent. In the example above, the significance factor of the predictionmodel [389, 73], i.e., (618−389)/73=3.1, is chosen to be the event'ssignificance factor. As will be explained below in connection with FIG.8B, this significance factor is used for determining whether the eventshould be displayed to a user or not.

In some embodiments, the event detection servers 180 also use the modelsto predict the minimum and maximum of the expected value for thatparticular time period (740-4). This value gives a user a range of anormal value for that time period had there been no anomalous useractivities. In some embodiments, the predicted metric values accordingto different models are ordered by their magnitudes. For example, 10models result in a sequence of 10 predicted values. Among the 10predicted values, the second to the lowest value is chosen to be theminimum of the expected value and the second to the highest value ischosen to be the maximum of the expected value if the actual value isoutside the range defined by the pair of (minimum, maximum). Otherwise,no minimum or maximum values are available for the corresponding event.

Compared with the model-based event detection that requires little userinteraction, the rule-based event detection described below provides anend user with more control on what kind of user activities may bepotentially “interesting” or valuable. Since these two approaches areoften complimentary to each other, they may provide better outcomes ifused in combination.

FIG. 7C is a flow chart of a rule-based process for detecting events ofpotential interest in a time series in accordance with some embodiments.

For a data source (e.g., a web site), the event detection servers 180identify one or more alert rules (770) in the alert rules database 195.In some embodiments, the event detection servers 180 query the alertrules database 195 for any alert rules that may be applicable to thetime series associated with the data source. The alert rules database195 stores a plurality of user-specified event triggering conditionsthat different users enter through a graphical user interface at aclient 110, an example of which is described below in connection withFIG. 12E. In some embodiments, the alert rules may be stored in the samedatabase as the dataset segment schemes supported by the analyticssystem 140.

The event detection servers 180 select one of the identified alert rules(772) and apply the alert rule to the time series database 175 toidentify those time series, if any, that satisfy the alert rule (774)and store them in the events database 195 as trigging events (778). Forexample, if the time series is a sequence of numbers of visits fromvisitors in China, the application of an alert rule that triggers anevent if the visits from China increase by 10% would be appropriate(although the time series may fail to trigger such event if the recenttime series update does not show at least 10% increase of visits). Incontrast, another alert rule that triggers an event if the visits fromBrazil drop 5% would not be applicable.

The event detector servers 180 repeat the aforementioned process untilthe last alert rule associated with the data source has been processed(780, yes). In some embodiments, these triggering events will be shownto a user through a graphical user interface per the user's request. Insome other embodiments, the analytics system 140 also notifies the userof the triggering event through other communication channels such asemail, text messaging, voicemail, etc.

The aforementioned description focuses primarily on how the analyticssystem 140 detects events of potential interest in the collected webanalytics data through data aggregation and time series data analysis.The following description shifts its focus on how the events ofpotential interest are served to the users of the analytics system 140in a client-server environment like the one shown in FIG. 1B.

FIGS. 8A and 8B are flow charts illustrating how the analytics systemprepares and serves a report of events of interest in response to a userrequest in accordance with some embodiments.

At a client 110, a user submits a request for viewing an event reportfor a particular web site. Upon receipt of the user request (802), theclient 110 generates a request for the event report to the analyticssystem 140 (804). In some embodiments, the client request is an HTTPrequest. Upon receiving the client request (806), the query processor190 in the analytics system 140 transforms the client request into oneor more queries to the events database 185 and submits them to thedatabase (810). For each of the database queries received from the queryprocessor 190 (812), the events database 185 identifies thecorresponding events data records (if any) (814) and returns them to thequery processor 190 for preparing a response to the client request(816).

As shown in FIG. 8B, the request from the client 110 includes a range ofdates and a sensitivity level for querying the events database (814-1).After determining the dates and the sensitivity threshold (814-1), theevents database 185 chooses one of the dates for further processing(814-2). The further processing includes retrieving events associatedwith the chosen date (814-3); identifying and counting the events whoserespective significance factors are at least equal to or higher than theuser-specified sensitivity threshold (814-4); and generating a datasetsegment scheme for event identified event (814-5). After looping throughall the dates (814-6, yes), the events database 185 returns theinformation about the identified events to the query processor 190.

Back to the side of the query processor 190, it compiles an event reportusing the events information returned from the events database 185 (818)and then returns the report to the client 110 (820). Upon receiving theevent report (822), the client 110 displays the report to the user(824). Exemplary screenshots of the graphical user interface fordisplaying the event reports are described below in connection withFIGS. 11A to 11C.

FIG. 9 is a block diagram of a client device used by, e.g., a webanalyst, for requesting and rendering web analytics reports inaccordance with some embodiments. The client 110 generally includes oneor more processing units (CPU's) 902, one or more network or othercommunications interfaces 904, memory 912, and one or more communicationbuses 914 for interconnecting these components. The communication buses914 may include circuitry (sometimes called a chipset) thatinterconnects and controls communications between components. The client110 may optionally include a user interface 905, for instance, a display906, a keyboard and/or mouse 908, and a touch-sensitive surface 909.Memory 912 may include high speed random access memory, such as DRAM,SRAM, DDR RAM or other random access solid state memory devices; and mayalso include non-volatile memory, such as one or more magnetic diskstorage devices, optical disk storage devices, flash memory devices, orother non-volatile solid state storage devices. Memory 912 may includemass storage that is remotely located from the central processingunit(s) 902. Memory 912, or alternately the non-volatile memorydevice(s) within memory 912, comprises a computer readable storagemedium. Memory 912 or the computer readable storage medium of memory 912stores the following elements, or a subset of these elements, and mayalso include additional elements:

-   -   an operating system 916 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 918 that is used for connecting        the client 110 to other servers or computers including the        analytics system 140 via one or more communication network        interfaces 904 (wired or wireless), such as the Internet, other        wide area networks, local area networks, and metropolitan area        networks and so on;    -   a client application 112 (e.g., a web browser), including one or        more client assistants 114 (e.g., toolbar, browser plug-in) for        monitoring the activities of a user; in some embodiments, the        client assistant 114, or a portion thereof, may include a web        application manager 520 for managing the user interactions with        the web browser, a data renderer 922 for supporting the        visualization of an analytics report, and a request dispatcher        924 for submitting user requests for new analytics reports; and    -   a user interface module 926, including a view module 928 and a        controller module 930, for detecting user instructions to        control the visualization of the analytics reports. In some        embodiments, the user interface module 926 further includes a        segmentation module 932 for displaying a segmentation/filter        definition template and receiving user instructions for building        a dataset segment scheme using the template and an alert module        934 for displaying an alert definition template and receiving        user instructions for building an alert rule using the template        (see, e.g., descriptions below in connection with FIGS. 12D and        12E).

FIG. 10 is a block diagram of an analytics system for processing webtraffic data, identifying events of potential interest therein, andserving web analytics reports in response to user requests in accordancewith some embodiments. The analytics system 140 generally includes oneor more processing units (CPU's) 1002, one or more network or othercommunications interfaces 1004, memory 1012, and one or morecommunication buses 1014 for interconnecting these components. Theanalytics system 140 may optionally include a user interface 1005comprising a display device 1006 and a keyboard 1008. Memory 1012includes high-speed random access memory, such as DRAM, SRAM, DDR RAM orother random access solid state memory devices; and may includenon-volatile memory, such as one or more magnetic disk storage devices,optical disk storage devices, flash memory devices, or othernon-volatile solid state storage devices. Memory 1012 may optionallyinclude one or more storage devices remotely located from the CPU(s)1002. Memory 1012, or alternately the non-volatile memory device(s)within memory 1012, comprises a computer readable storage medium. Memory1012 or the computer readable storage medium of memory 1012 stores thefollowing elements, or a subset of these elements, and may also includeadditional elements:

-   -   an operating system 1016 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 1018 that is used for connecting        the analytics system 140 to other computers such as the clients        110 (used by the web analyst or a regular website user) and the        web servers 120 via the communication network interfaces 1004        (wired or wireless) and one or more communication networks, such        as the Internet, other wide area networks, local area networks,        metropolitan area networks, and so on;    -   one or more log processors 150 for processing the web traffic        data received from the web servers 120 and the clients 110 into        sessionized data records stored in the hits database 155;    -   one or more aggregation servers 160 for aggregating the        different metrics of the sessionized data into the aggregated        data in the aggregates database 165;    -   one or more time series gathering servers 170 for organizing the        different aggregated metrics data in the aggregates database 165        into time series in the time series database 175; in some        embodiments, the time series gathering servers 170 include a        time series update module 1020 for updating the time series with        the aggregated data updates received from the aggregates        database 165;    -   one or more event detection servers 180 for detecting events of        potential interest in the time series stored in the time series        database 175; in some embodiments, the event detection servers        180 include an event detection module 1022, a model prediction        module 1024 for making predictions based on the time series, and        an alert detection module 1026 for identifying events in the        time series that triggers one or more alert rules in the alert        rules database 195; in some embodiments, the model prediction        module 1024 further includes one or more parameters 1024-1 such        as α, γ in the double exponential smoothing, a linear regression        sub-module 1024-2, a Holt-Winters exponential smoothing        sub-module 1024-3, as well as other models 1024-4;    -   a query processor 190 for querying the databases associated with        the analytics system 140 in response to user requests from        clients 110 and providing analytics reports to the clients 110        based on the query results; in some embodiments, the query        processor 190 further includes a server application 194 that        includes a query module 1030 for converting client requests into        one or more queries or data filters and a response module 1032        for preparing analytics reports based on the response from the        different databases;    -   a hits database 155 for storing sessionized web analytics data;    -   an aggregates database 165 for storing the aggregated metric        data and their associated conditions;    -   a time series database 175 for storing the time series extracted        from the aggregates database 165;    -   an events database 185 for storing the events of potential        interest identified in the time series; and    -   an alert rules database 195 for storing user-specified alert        definitions; in some embodiments, the alert rules database 195        includes one or more alert rule definitions such as the alert        rule A 1034-1 including the associated metric(s) 1034-2 and the        condition(s) 1034-3, the alert rule B 1034-4, etc.

Each of the above-identified elements may be stored in one or more ofthe previously mentioned memory devices, and corresponds to a set ofinstructions for performing a function described above. The aboveidentified modules or programs (i.e., sets of instructions) need not beimplemented as separate software programs, procedures or modules, andthus various subsets of these modules may be combined or otherwisere-arranged in various embodiments. In some embodiments, memory 912 and1012 may store a subset of the modules and data structures identifiedabove. Furthermore, memory 912 and 1012 may store additional modules anddata structures not described above.

FIGS. 9 and 10 are intended more as functional descriptions of thevarious features of a client device and analytics system rather than astructural schematic of the embodiments described herein. In practice,and as recognized by those of ordinary skill in the art, items shownseparately could be combined and some items could be separated. Forexample, some items shown separately in FIG. 10 like the query processor190 and the server application 194 as well as items like the databases155 to 195 could be implemented by one or more servers. The actualnumber of server computers used to implement the analytics system 140,and how features are allocated among them will vary from oneimplementation to another, and may depend in part on the amount of datatraffic that the system must handle during peak usage periods as well asduring average usage periods.

FIGS. 11A to 11C are screenshots of graphical user interfaces thatdisplay daily, weekly, and monthly events of potential interest,respectively, in accordance with some embodiments.

In particular, FIG. 11A depicts a daily alerts graphical user interface1102 during a 30-day period from Sep. 15, 2009 to Oct. 15, 2009. Toaccess this user interface, a user clicks the “Intelligence” entry 1100on the left side of the interface. There are three levels of alerts inthe “Intelligence” entry 1100, “Daily Alerts,” “Weekly Alerts,” and“Monthly Alerts.” In some embodiments, the user interface by defaultdisplays the daily alerts when the user clicks the entry 1100. Below thedaily visits curve 1101 is a bar chart 1104 illustrating the respectivetotal number of events of potential interest during the 30-day period,each day occupying one clickable spot in the bar chart 1104. In someembodiments, the user interface automatically focuses on the entry onthe far right of the bar chart, which corresponds to the current date,Oct. 15, 2009. But a user can click on other parts of the bar chart 1104to investigate the alert information for any other day within the last30 days. Note that, at the current sensitivity level 1112, the totalnumber of events 1106 for the date of Oct. 15, 2009 (referred to as“alerts” in the figure) is zero. In other words, the analytics system140 does not identify any anomalous user activity patterns for that dayunder the current sensitivity level 1112. As a result, the custom alertsregion 1108, which is associated with the “Custom Alerts” checkbox 1103and used for displaying those alert rule-based events, and the automaticalerts region 1110, which is associated with the “Automatic Alerts”checkbox 1105 and used for displaying those model-based events, are bothempty. Note that a de-selection of either checkboxes 1103 or 1105removes the corresponding alert regions 1108 or 1110 from the graphicaluser interface.

FIG. 11B depicts a weekly alerts graphical user interface 1120 for thepast five weeks from Sep. 13, 2009 to Oct. 15, 2009, e.g., after a userselection of the “Weekly Alerts” link 1124 on the left of the userinterface. By default, the current week of Oct. 11-15, 2009 ishighlighted in the user interface. A user can click on the bar chartbelow the curve 1122 to select another week of data. Note that there isno alert for the current week including Oct. 15, 2009 because it is notover yet and the forecasting of the present application is for the mostrecently completed week. Compared with the curve 1101 in FIG. 11A, thecurve 1122, which corresponds to roughly the same period of time, issmoother because, as explained above, the weekly summation of the dailydata samples acts as a low-pass filter. As a result, the number ofweekly alerts during each week is typically smaller than the sum ofdaily alerts during the same week. This also applies to the monthlyalert described below in connection with FIG. 11C. This user interfaceis similar to the one shown in FIG. 11A except that the total numbers ofdata samples as shown in the curve 1122 drop from 30 (which correspondsto the last 30 days from Sep. 15, 2009 to Oct. 15, 2009) to 5 (whichcorresponds to the last five weeks from September 13, 2009 to October15, 2009). In this example, the number of alerts for the week of Oct.11-15, 2009 remains to be zero under the current sensitivity level.

FIG. 11C depicts a monthly alerts graphical user interface 1140 for thepast 12 months from Oct. 1, 2008 to Oct. 15, 2009, after a userselection of the “Monthly Alerts” 1144 on the left. This user interfaceis similar to the one shown in FIG. 11A except that the total numbers ofdata samples as shown in the curve 1142 drop from 30 to 12. In thisexample, the number of alerts for the month of Oct. 1-15, 2009 remainsto be zero under the current sensitivity level.

FIGS. 12A to 12E are screenshots of graphical user interfaces thatdisplays information relating to events of potential interest inaccordance with some embodiments.

FIG. 12A depicts the same daily alerts 1102 shown in FIG. 11A but at adifferent date, Sep. 30, 2009. According to this daily alerts 1202, thenumber of alerts 1204 on Sep. 30, 2009 at the current sensitivity level1212 is three. Note that the custom alerts region 1206 is empty and allthe three alerts are model-based automatic alerts. In particular, one ofthe alerts 1208 suggests a significant (83%) drop of bounce rate forvisits that exit from a particular web page 1209 from the expected rangeof 34.26%-39.96% to 6.29% . A visual indication 1211 of the alert'ssignificance factor is also shown in the same row, indicating howunlikely this alert is under a normal situation. Two alerts 1210, 1214are grouped together under the label “Visits.” Note that although thesetwo alerts are both related to the number of visits to the website (inthis case, www.googlestore.com), they have different conditions andtherefore have different meanings. The alert 1210 indicates that thenumber of visits to the website that exit the website from the web pagewww.googlestore.com/default.asp” during Sep. 30, 2009 increased morethan 500% when compared with the median value derived from the multipleprediction models. The expected range from 0 to 458 is determined usingthe method described above in connection with FIGS. 7A and 7B.

In contrast, the alert 1214 indicates that the number of visits to thewebsite that were referred to the website from the web page“www.google.com/intl/en/about.html” during Sep. 30, 2009 increased morethan 281% when compared with the median value derived from the multipleprediction models. This may be because that the referral web page has alink to the website www.goolestore.com and many users who visit Google'swebsite found that link and then clicked it through.

In some other embodiments, the reference value used for measuring thepercentage may be the actual value of the immediately preceding timeperiod, the averaged actual value derived from multiple time periods inthe past, the mean of the expected range or other reference values thatare well-known in the art.

FIG. 12B depicts a graphical user interface 1220 when the user-selecteddate moves from Sep. 30, 2009 to Oct. 14, 2009. Note that the number ofalerts for the new dates increases to 20. Moreover, one of the 20 alertsis a custom alert 1226 called “revenue decrease.” A user selection ofthe edit link 1228 brings up the definition of the custom alert as shownin FIG. 12E. According to the definition, this alert is triggered whenthe revenue from all traffic to the website drops more than 10% from thesame day of the previous week. In other words, the revenue on Oct. 14,2009 is less than 90% of the revenue on Oct. 7, 2009.

FIG. 12C depicts the same user interface after a user selection of thecurve link 1248 next to the first automatic alert 1244, which indicatesa dramatic increase of goal conversion rate of the total traffic. Asshown by the curve 1246, the rate was almost zero for the entire monthuntil a sudden jump on Oct. 14, 2009. This curve also explains how thejump is detected as an alert. Using this alert as a lead, the webanalyst can investigate the type of traffic on the same date andresearch what triggers the sudden jump of goal conversion rate.

FIG. 12D depicts a graphical user interface for defining a datasetsegment scheme in response to a user selection of the “Create segment”link 1242 in FIG. 12C. A more detailed description of the datasetsegment scheme can be found in the pending U.S. patent application Ser.Nos. 12/575,435 and 12/575,437, both of which are incorporated into thisapplication by reference in their entirety. Note that this featureallows a user to revisit the dataset through the same visualizationangle in the future without relying on the events report, which is veryuseful for helping a user to understand the dataset.

FIGS. 13A to 13C are screenshots of graphical user interfaces thatdisplay different numbers of events of potential interest based on arespective user-specified sensitivity threshold in accordance with someembodiments.

FIG. 13A depicts the alerts bar chart when the sensitivity level isabout in the middle level 1310. FIG. 13B depicts the alerts bar chartwhen the sensitivity level reaches the highest level 1320. In this case,the analytics system 140 reports not only more (12 of FIG. 13B vs. 3 ofFIG. 13A) alerts or events of potential interest for the same date, Sep.30, 2009, but also one or more alerts for many other dates that have noalerts reported in FIG. 13A. By contrast, FIG. 13C depicts the alertsbar chart when the sensitivity level reaches the lowest level 1330. Inthis case, the analytics system 140 reports zero alert for the samedate, Sep. 30, 2009.

FIGS. 14A and 14B are screenshots of graphical user interfaces thatdisplay events of potential interest based on a respectiveuser-specified organization manner in accordance with some embodiments.In particular, FIG. 14A depicts a graphical user interface in which thealerts are displayed in an order defined by dimension 1410 such as theAll Traffic 1412 and the Visitor 1414 and then by different metricswithin the same dimension. FIG. 14B depicts a graphical user interfacein which the alerts are displayed in an order defined by metric 1420such as the Goal Conversion Rate 1422 and then by different dimensionswithin the same metric.

FIG. 15A depicts a flow chart of a method for identifying anomalies intime series data in accordance with some embodiments. At a server systemwith a processor and memory, the server system stores time series datafor a data source (1501). The time series data comprises a plurality oftime-value pairs, each pair including a value of one or more attributesassociated with the data source and a time associated with the value.

For a particular attribute, the server system generates a plurality offorecasting models for characterizing the time-value pairs in arespective subset of the time series data (1503). In some embodiments,each forecasting model includes an estimated attribute value and anassociated error-variance.

For a respective time-value pair associated with the particularattribute, the server system determines whether the value of thetime-value pair is within the error-variance of the correspondingestimated attribute value and tags the time-value pair as an anomaly ifthe value of the time-value pair is outside the error variance for atleast a first subset of the forecasting models (1505).

Finally, in response to a request from a client application foranalytics information for the data source, the sever system reports tothe client application at least a subset of the time-value pairs taggedas anomalies for one or more of the attributes (1507).

In some embodiments, the respective time-value pair for the particularattribute is the latest time-value pair from the data source. The firstsubset of the forecasting models comprises one of: a predeterminednumber of the forecasting models or a predetermined fraction of theforecasting models.

As shown in FIG. 15B, for the respective time-value pair and theparticular attribute, the server system determines a significance factor(1511). In some embodiments, the significance factor is chosen suchthat, when the error-variance for each of the forecasting models ismultiplied by the significance factor, the value of the time-value pairis inside the factored error-variance of a corresponding estimatedmetric value for at least a second subset of the forecasting models andthe first subset is within the second subset.

In response to the request from the client application for analyticsinformation that includes a significance threshold for one or more ofthe attributes, the server system reports to the client applicationthose time-value pairs tagged as anomalies when the respectivesignificance factor for each of the time-value pairs exceeds thesignificance threshold (1513).

In some embodiments, the forecasting models include at least one of alinear regression model and a Holt-Winters exponential smoothing model.The forecast models include models computed from 4, 21, and 56 days oftime-series data.

In some embodiments, the time series data includes aggregated webanalytics data, the method further comprising: aggregating raw orsessionized web traffic data to generate the aggregated web analyticsdata for attributes of interest and storing the aggregated web analyticsdata in addition to the raw or sessionized web traffic data. The timeseries data includes sessionized web analytics data, the method furthercomprising: summarizing per session raw web traffic data to generate thesessionized time series data for one or more of the attributes storingthe sessionized time series data in addition to the raw web trafficdata.

FIG. 16A depicts another flow chart of a method for identifyinganomalies in time series data implemented by different components of aserver system with a processor and memory in accordance with someembodiments.

A time series data collector of the server system is configured tocollect time series data at one or more predefined time intervals from aplurality of data sources (1601). In some embodiments, the time seriesdata comprises a plurality of time-value pairs, each pair including avalue of one attribute associated with the data sources and a time whenthe value was collected.

A time series storage module of the server system is configured to storethe collected time series data in a computer memory such that, when anew time-value pair is collected by the time series data collector, thenew time-value pair is added to the stored time series data for arespective collection of time series data without disturbing thepreviously stored time series data for the respective collection (1603).

For a particular new time-value pair, an anomaly detection module of theserver system is configured to determine whether the particular newtime-value pair is an anomaly with reference to its associatedcollection of time series data (1605). In some embodiments, thisoperation further includes: generating a plurality of forecasting modelscharacterizing different subsets of the associated collection of timeseries data (1605-1), each forecasting model including an estimatedattribute value and an associated error-variance; determining whetherthe particular new time-value pair is within the associatederror-variance for each of the plurality of forecasting models (1605-3);and tagging the particular time-value pair as an anomaly when the valueof the particular time-value pair is outside the error-variance for atleast a first subset of the forecasting models (1605-5).

Next, an anomaly storage module of the server system is configured tostore the time-value pairs tagged as anomalies such that the storedtime-value pairs are ready to be served to a user at a clientapplication in response to a user request for the anomalies.

In some embodiments shown in FIG. 16B, the server system also includesan aggregation module configured to generate aggregated time series datafrom the collected time series data (1611). The aggregate time seriessummarizes raw time series data or sessionized time series data forparticular attributes of interest associated with the data sources, theaggregate data being stored by the time series storage module inaddition to stored raw time series data or sessionized time series data.

In some embodiments, the anomaly detection mechanism operates solely onthe aggregated time series data generated by the aggregation module. Thedata sources are web pages stored on web servers and the collected timeseries data comprises values of metrics and dimensions for the web pagesand associated time values when the values of the metrics and dimensionswere collected. The predefined time intervals are no longer than a day.

In some embodiments, the time series storage module is furtherconfigured to quantize and compress the time series data before storingit so as to save more space.

In some embodiments, the collection of time series data includes anumber of time-value pairs that is used for generating the plurality offorecasting models and the forecasting models include at least one of alinear regression model and a Holt-Winters exponential smoothing model.

FIG. 17A depicts another flow chart of a method for detecting anomaliesin web analytics data implemented at a server system in accordance withsome embodiments.

The server system stores web analytics data for a web page in a device(1701). In some embodiments, the web analytics data comprises aplurality of prior time-value pairs, each time-value pair including avalue of one of a plurality of attributes associated with the web pageand a time associated with the value. The server system collects a newtime-value pair for the particular attribute (1703). The new time-valuepair includes a new value associated with the web page and a new timewhen the value was determined.

For each of the set of predicted values, the server system estimates aset of predicted values for the attribute and associated error-variancesat the new time by applying a plurality of forecasting models to theplurality of prior time-value pairs in respective subsets of the webanalytics data (1705).

Finally, the server system tags the collected new time-value pair as ananomaly when the value of the new time-value pair is outside the errorvariance of each of a first subset of the forecasting models for theparticular attribute (1707).

FIG. 17B depicts that the server system adds to the collected webanalytics data for the web page the new time-value pair (1711). Thetime-value pair includes a tag indicating whether the new value is ananomaly and a significance factor if the new value is an anomaly.

FIG. 17C depicts that the server system storing the web analytics datafor a fixed time window into the past (1721). After estimating the setof predicted values and associated error-variances for the attribute atthe new time, the server system deletes one or older time-value pairsfrom previously collected time series data (1723) and appends the newtime-value pair to the end of the collected web analytics data (1725).

In some embodiments, the attributes comprise a plurality of metrics anddimensions associated with the web site.

As shown in FIGS. 11A to 11C, the graphical user interface forpresenting time series data and anomalies for a data source includes afirst window and a second window below the first window.

In some embodiments, the first window includes a graph of time seriesdata values for a first attribute for the data source, the graph havinga time axis corresponding to a time range and a dependent data valueaxis, and a histogram of anomalies for the data source, with the sametime axis scale as the graph and a dependent total anomalies axis. Notethat the height of a respective bar along the total anomalies axis inthe histogram represents the total number of anomalies for the web siteat a particular day.

The second window includes a list of items characterizing a set ofanomalies at a particular time on the time axis, each item correspondingto an anomaly associated with a respective attribute for the datasource, a value of the respective attribute at the particular time, anda significance factor of the anomaly, and a user-interactive object foradjusting a sensitivity threshold associated with the first window andthe second window.

As further depicted in FIGS. 13A to 13C, in response to a useradjustment of the sensitivity threshold through the user-interactiveobject, a new histogram of anomalies for the data source is rendered toreplace the existing histogram of anomalies for the data source in thefirst window. In addition, a new list of items characterizing a new setof anomalies at the particular time is rendered to replace the existinglist of items.

Although some of the various drawings illustrate a number of logicalstages in a particular order, stages which are not order dependent maybe reordered and other stages may be combined or broken out. While somereordering or other groupings are specifically mentioned, others will beobvious to those of ordinary skill in the art and so do not present anexhaustive list of alternatives. Moreover, it should be recognized thatthe stages could be implemented in hardware, firmware, software or anycombination thereof.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the invention and its practical applications, to therebyenable others skilled in the art to best utilize the invention andvarious embodiments with various modifications as are suited to theparticular use contemplated.

1. A graphical user interface for presenting time series data andanomalies associated with a data source on a display of a clientcomputer having a user input device, comprising: a first window on thedisplay that includes: a graph of time series data values for arespective attribute of the data source, the graph having a time axiscorresponding to a time range and a dependent data value axis, and ahistogram of anomalies of the data source, each of the anomaliescorresponding to a value of a respective attribute that is substantiallydifferent from an expected value of the attribute, the histogram havingthe same time axis scale as the graph and a dependent total anomaliesaxis, wherein the height of a respective bar along the total anomaliesaxis represents a total number of anomalies of the data source for acorresponding time on the time axis; and a second window on the displaythat includes: a list of automatic alerts characterizing a set ofanomalies of the data source at a particular time on the time axis, theparticular time being designated by a user via interaction with thegraph through the user input device, each item in the list of automaticalerts corresponding to an anomaly associated with a respectiveattribute for the data source.
 2. The graphical user interface of claim1, wherein each item in the list of automatic alerts includes arepresentation of a significance factor of a respective anomaly, thesignificance factor indicating an extent to which the value of anattribute is different from the expected value of the attribute.
 3. Thegraphical user interface of claim 2, wherein each of the significancefactors is determined in accordance with error-variances of a pluralityof forecasting models as applied to the associated time series data andthe value of the attribute.
 4. The graphical user interface of claim 1,wherein each item in the list of automatic alerts further includes arepresentation of an expected range of an attribute at a particular timeand a percentage difference between the value of the attribute and theexpected value of the attribute at the particular time.
 5. The graphicaluser interface of claim 1, wherein each item in the list of automaticalerts includes a user selectable link that enables a user to initiatecreation of an analytics segment for future analysis of time series dataof the data source based on a corresponding attribute.
 6. The graphicaluser interface of claim 1, wherein the second window further includes alist of custom alerts, each of the custom alerts indicating when auser-provided condition relating to a respective attribute of the datasource has occurred at a particular time, each of the custom alertsincluding an identifier of the custom alert and a value of therespective attribute at the particular time.
 7. The graphical userinterface of claim 6, further comprising display control elements thatenable a user to control display of the custom alerts and/or theautomatic alerts.
 8. The graphical user interface of claim 1, whereineach of the anomalies is associated with a significance factorindicating a degree to which a value of an associated attribute issubstantially different from an expected value of the associatedattribute, further comprising: a user-interactive object for adjusting asensitivity threshold associated with the first window and the secondwindow; wherein: in response to a user adjustment of the sensitivitythreshold through the user-interactive object: a new histogram ofanomalies for the data source is rendered to replace the existinghistogram of anomalies for the data source in the first window; and anew list of items characterizing a new set of anomalies at theparticular time is rendered to replace the existing list of items; thenew histogram and the new list including information for only thoseanomalies whose associated significance factors are consistent with theuser-adjusted sensitivity threshold.
 9. The graphical user interface ofclaim 8, wherein the new set of anomalies includes fewer items inresponse to user selection of lower sensitivity thresholds and moreitems in response to user selection of higher sensitivity thresholds.10. The graphical user interface of claim 1, wherein the time axis scaleis one of: day, week or month.
 11. The graphical user interface of claim1, wherein the automatic alerts are grouped in relation to a respectivemeasure of the data source that is related to the values of theassociated attributes.
 12. The graphical user interface of claim 1,wherein the respective measure is one of: conversion rate,visits/sessions, visitors, bounce rate, page views, revenue or time. 13.A computer-implemented method for presenting on a display time seriesdata and anomalies associated with a data source, comprising: displayinga graphical user interface, the graphical user interface including: afirst window on the display that includes: a graph of time series datavalues for a respective attribute of the data source, the graph having atime axis corresponding to a time range and a dependent data value axis,and a histogram of anomalies of the data source, each of the anomaliescorresponding to a value of a respective attribute that is substantiallydifferent from an expected value of the attribute, the histogram havingthe same time axis scale as the graph and a dependent total anomaliesaxis, wherein the height of a respective bar along the total anomaliesaxis represents a total number of anomalies of the data source for acorresponding time on the time axis; and a second window on the displaythat includes: a list of automatic alerts characterizing a set ofanomalies of the data source at a particular time on the time axis, theparticular time being designated by a user via interaction with thegraph through the user input device, each item in the list of automaticalerts corresponding to an anomaly associated with a respectiveattribute for the data source; and a user-interactive object foradjusting a sensitivity threshold associated with the first window andthe second window; in response to a user adjustment of the sensitivitythreshold through the user-interactive object, replacing the existinghistogram of anomalies for the data source in the first window with anew histogram of anomalies for the data source in the first window; andreplacing the existing list of items with a new list of itemscharacterizing a new set of anomalies at the particular time in thesecond window.
 14. The computer-implemented method of claim 13, whereinthe new histogram and the new list include information for only thoseanomalies whose associated significance factors are consistent with theadjusted sensitivity threshold.
 15. The computer-implemented method ofclaim 13, wherein each item in the list of automatic alerts includes arepresentation of a significance factor of the respective anomaly, thesignificance factor indicating an extent to which the value of theassociated attribute is different from the expected value of theattribute.
 16. The computer-implemented method of claim 15, wherein eachof the significance factors is determined in accordance with variancesof a plurality of forecasting models as applied to the associated timeseries data and the value of the associated attribute.
 17. Thecomputer-implemented method of claim 13, wherein each item in the listof automatic alerts further includes a representation of an expectedrange of an attribute at the particular time and a percentage differencebetween the value of the attribute and the expected value of theattribute at the particular time.
 18. The computer-implemented method ofclaim 13, wherein each item in the list of automatic alerts includes auser selectable link that enables a user to initiate creation of ananalytics segment for future analysis of time series data for the datasource based on a corresponding attribute.
 19. The computer-implementedmethod of claim 13, wherein the second window further comprises a listof custom alerts, each of the custom alerts indicating when auser-provided condition relating to a respective attribute of the datasource has occurred at a particular time, each of the custom alertsincluding an identifier of the custom alert and a value of therespective attribute at the particular time.
 20. Thecomputer-implemented method of claim 19, wherein the new set ofanomalies includes fewer items in response to user selection of lowersensitivity thresholds and more items in response to user selection ofhigher sensitivity thresholds.
 21. The computer-implemented method ofclaim 13, wherein the time axis scale is one of: day, week or month. 22.The computer-implemented method of claim 13, wherein the automaticalerts are grouped in relation to a respective measure of the datasource that is related to the values associated with the associatedattributes.
 23. The computer-implemented method of claim 13, wherein therespective measure is one of: conversion rate, visits/sessions,visitors, bounce rate, page views, revenue or time.
 24. A computerreadable-storage medium storing one or more programs for execution byone or more processors of a computer for displaying anomalies in timeseries data, the one or more programs comprising instructions for:displaying a graphical user interface, the graphical user interfaceincluding: a first window on the display that includes: a graph of timeseries data values for a respective attribute of the data source, thegraph having a time axis corresponding to a time range and a dependentdata value axis, and a histogram of anomalies of the data source, eachof the anomalies corresponding to a value of a respective attribute thatis substantially different from an expected value of the attribute, thehistogram having the same time axis scale as the graph and a dependenttotal anomalies axis, wherein the height of a respective bar along thetotal anomalies axis represents a total number of anomalies of the datasource for a corresponding time on the time axis; and a second window onthe display that includes: a list of automatic alerts characterizing aset of anomalies of the data source at a particular time on the timeaxis, the particular time being designated by a user via interactionwith the graph through the user input device, each item in the list ofautomatic alerts corresponding to an anomaly associated with arespective attribute for the data source; and a user-interactive objectfor adjusting a sensitivity threshold associated with the first windowand the second window; in response to a user adjustment of thesensitivity threshold through the user-interactive object, replacing theexisting histogram of anomalies for the data source in the first windowwith a new histogram of anomalies for the data source in the firstwindow; and replacing the existing list of items with a new list ofitems characterizing a new set of anomalies at the particular time inthe second window.